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The  roost  well-known  program  verification  technique  is  based 
upon  the  Floyd-Naur  idea  of  inductive  assertions  [4] :  A  programming 
language  command  inposes  certain  fixed  implications  between  the 
relations  holding  among  the  values  of  program  variables  just  before 
and  just  after  the  execution  of  that  command.  The  (partial)  cor¬ 
rectness  of  a  program  can  thus  be  proved  if  the  output  specification 
claimed  at  the  program  exit  are  derived  from  the  input  specifications 
assumed  at  the  entrance  by  following  the  chain  of  implications 
mentioned  above  for  all  entrance-to-exit  control  flow  paths  in 
the  program.  Usually,  this  requires  1)  the  invention  of  a  number 
of  assertions  associated  with  some  key  points  ("cutpoints")  in 
the  program  2)  the  generation  of  the  implications  mentioned  above 
("verification  conditions")  for  every  pair  of  adjacent  points 
chosen,  and  3)  the  demonstration  (possibly,  using  the  services 
of  a  theorem-prover)  that  each  of  these  implications  is  true. 

Of  these,  the  second  task  —  the  generation  of  verification  condi¬ 
tions  is  strictly  a  mechanical  process  requiring  substitution  and 
simple  arithmetical  evaluation.  The  lambda- calculus  has  built-in 
rules  to  carry  out  the  process  of  substitution  and  can  be  easily 
augmented  with  arithmetical  evaluation  rules.  Thus,  it  seems 
reasonable  to  seek  a  lambda-calculus-based  method  for  the  automatic 
generation  of  verification  conditions. 

In  this  paper  we  develop  such  a  method.  It  has  been  obtained 
by  extending  an  existing  [1]  lambda-calculus  model  of  programming 
languages  in  which  programs  are  translated  into  lambda-expressions 
such  that  the  (numerical)  execution  of  programs  is  modelled  by  the 
lambda-calculus  process  of  reduction.  In  the  new  model,  a  program 
is  effectively  translated  into  a  lambda-expression  whose  reduction 
yields  a  list  of  all  verification  conditions.  The  extension  from 
the  previous  to  the  new  model  is  non-trivial,  for  we  are  now 
interested  in  a  sense  in  the  symbolic,  rather  than  numerical, 
evaluation  of  programs. 

For  generating  verification  conditions,  one  must  have  a 
program  as  well  as  inductive  assertions  associated  with  certain 
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properly  chosen  cutpoints  in  the  program.  We  specify  a  programming 
language  in  which  inductive  assertions  are  incorporated  within 
the  program  body  by  means  of  special  assert  statements.  Equipped 
with  assignments/  conditionals,  compounds,  ALGOL- type  blocks, 
and  loops,  this  language  is  simple  yet  quite  powerful.  We  then 
present  a  set  of  translation  rules  mapping  the  statements  of 
the  specified  programming  language  into  lambda-expressions. 

Using  these  rules,  a  program  can  be  effectively  translated  into 
a  lambda-expression,  say  by  extending  the  compiler  of  [5], 

Finally,  we  show  that  the  model  is  correct  in  the  sense  that 
the  translation  of  any  program  produced  by  our  rules  does  indeed 
give  all  verification  conditions. 
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Verification  Conditions 

Given  a  program,  in  the  flowchart  form,  say,  and  the  program 
input  and  output  conditions,  the  inductive  assertion  method  to 
prove  the  partial  correctness  of  the  program  proceeds  as  follows 
Cl4],  explanation  in  [7]).  First,  outpoints  are  chosen  on  the 
flowchart  edges  such  that  there  is  at  least  one  cutpoint  in  each 
loop.  Cutpoints  are  also  placed  on  the  start  and  halt  edges. 

Next,  to  each  cutpoint  is  associated  a  predicate  —  the  inductive 
assertion  —  which  is  intended  to  express  the  relation  holding 
among  the  values  of  the  program  variables  each  time  the  control 
passes  that  cutpoint.  The  desired  input  and  output  conditions  of 
the  program  serve  as  the  assertions  at  the  start  and  halt  cutpoints, 
respectively.  Next,  a  verification  condition  is  constructed  for 
each  basic  path  —  a  path  which  begins  and  ends  at  two  (not  neces¬ 
sarily  different)  cutpoints  but  does  not  pass  through  any  other 
cutpoint.  The  verification  condition  for  a  basic  path  a  from 
cutpoint  i  to  cutpoint  j  states  that  if  the  assertion  at  i  is  true 
and  the  control  traverses  a,  then  the  assertion  at  j  will  hold 
(with  the  new  values  of  variables  attained  at  j).  Finally,  each 
verification  is  proved  to  be  true.  By  induction  it  is  then  the 
case  that  the  assertion  at  each  cutpoint  is  true  whenever  control 
reaches  that  cutpoint  (assuming  that  the  input  condition  on  the 
start  edge  is  satisfied  at  the  initiation  of  program  execution) . 

In  particular,  the  assertion  at  the  halt  edge  is  true  whenever 
control  reaches  this  edge,  that  is,  whenever  the  program  halts. 

Thus  the  program  is  partially  correct  with  respect  to  the  given 
input  and  output  conditions. 

In  constructing  the  verification  condition  for  a  given  path, 

one  has  to  take  into  account  the  transformation  in  variable  values 

resulting  from  the  execution  of  the  statements  in  the  path.  For 

example,  let  a  path  consist  of  a  single  assignment  statement 

x:*x+l  and  let  the  assertions  at  the  beginning  and  the  end  of  the 
2  2 

path  be  x  +2x+3>0  and  x  +2>0,  respectively.  The  verification  con- 

2 

dition  should  be  equivalent  to  the  statement:  If  x  +2x+3  is  true 

for  some  value  of  x,  and  the  assignment  x:-x+l  is  executed,  then 
2 

x  +2>0  is  true  for  the  new  value  of  x.  Clearly  this  is  not 
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equivalent  to 

x2+2x+3>0  x2+2>0, 

2  2 

for  the  predicates  x  +2x+3>0  and  x  +2>0  hold  for  different  values 

of  xr  namely  those  respectively  before  and  after  the  execution 

of  x:=x+l.  We  can  "normalize"  the  predicates  so  as  to  make  them 

refer  to  the  same  values  of  x,  either  before  or  after  the  execution 

of  the  assignment  statement.  In  terms  of  the  values  existing  before 

2  2 

the  execution,  the  predicates  are  x  +2x+3>0  and  (x+1)  +2>0;  in  terms 

2 

of  the  values  after  the  execution,  they  are  (x-1)  +2(x-l)+3>0  and 

2  .  . 
x  +2>0.  The  verification  condition  can  then  be  written  in  the 

equivalent  forms 

x2+2x+3>0  3  (x+1) 2+2>0 

or,  (x-1)2+2 (x-1)+3>0  x2+2>0. 

In  general,  suppose  the  assertions  at  the  beginning  and  the 
end  of  a  path  a  are  P  and  Q,  respectively.  Then  the  verification 
condition  for  the  path  is  a  predicate  P'&RoQ',  where  R  represents 
the  condition  under  which  a  is  traversed  (R=true,  if  a  does  not  contain 
any  conditional  statement),  and  P',  Q'  are  obtained  from  P,  Q, 
respectively,  by  making  appropriate  substitutions  to  reflect  the 
changes  in  variable  values  effected  by  the  execution  of  statements 
in  o.  The  substitutions  should  be  done  so  as  to  make  P'  and  Q' 
refer  to  the  same  values  of  variables.  (R  should  be  derived  to  also 
correspond  to  the  same  values  of  variables.)  In  the  special  case 
that  the  predicates  are  to  be  expressed  in  terms  of  the  variable 
values  at  the  beginning  of  the  path,  P'  is  just  P,  and  Q'  is  formed 
from  Q  by  "backward  substitution"  (6] :  The  path  is  traced  backward 
and  for  every  assignment  statement  encountered,  the  assigned 
expression  is  substituted  for  the  assigned  variable;  the  cumulative 
effect  of  all  such  substitutions  is  to  transform  Q  into  Q' .  On 
the  other  hand,  if  the  predicates  are  to  be  expressed  in  terms 
of  the  variable  values  at  the  end  of  the  path,  then  Q'  is  just  Q, 
and  P'  is  obtained  from  P  by  an  analogous  process  of  "forward 
substitution. " 

Since  the  lambda- calc  ulus  ([3,9])  contains  built-in  rules  to 
carry  out  the  process  of  substitution,  it  is  possible  to  use 
a  lambda-calculus-based  method  for  the  automatic  generation  of 
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verification  conditions.  The  method  to  be  described  in  this 
paper  has  been  obtained  by  modifying  and  extending  the  lambda** 
calculus  model  of  programming  languages  described  in  [1].  This 
model  is  comprised  of  rules  for  translating  programs  written 
in  a  large  subset  of  ALGOL  60  (or  a  similar  language)  into 
lambda-expressions  in  such  a  manner  that  if  the  result  of  ex¬ 
ecuting  a  program  P  with  inputs  i^,...,i  consists  of  outputs 
o^,...,on,  then  the  lambda-expression  ({P}{i^}. . . { im> )  reduces 
to  the  tuple  or  list  <{o^} , . . . , {°n}>*  (Here,  (...)  denotes 
the  lambda- calculus  representation  of  the  enclosed  object. ) 

Based  upon  these  rules,  a  compiler  has  been  constructed  ([5]) 
to  translate  PASCAL  programs  into  lambda-expressions.  The  goal 
of  the  model  to  be  presented  in  this  paper  is  to  provide  rules 
for  translating  any  program  suitably  annotated  with  assertions 
into  a  lambda-expression  whose  reduction  yields  a  list  of  the 
lambda-calculus  representations  of  the  verification  conditions. 
To  distinguish  the  two  models ,  we  call  the  former  the  "execution 
model"  and  the  latter  the  "verification  model". 
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The  Source  Lane 


Before  giving  any  translation  rules  for  the  verification  model, 
we  must  specify  the  language,  call  it  PL,  in  which  the  programs 
acceptable  by  the  model  can  be  written.  This  language  contains 
the  following  features: 

1.  Integer  and  boolean  data  types 

2.  The  usual  arithmetical,  boolean,  and  relational  operators 

3.  Assignment  statements  of  the  form  variable  :=  expression 

4.  Input  and  output  statements  of  the  form 

read  variable  list 
write  expression  list 

5.  Conditional  statements  of  the  form 

if  condition  then  statement 

if  condition  then  statement  else  statement 

6.  Compound  statements  and  blocks  as  in  ALGOL  60. 

Inductive  assertions  associated  at  chosen  cutpoints  in  a  flowchart  are 
incorporated  directly  in  the  body  of  a  PL  program  by  means  of 
the  following  statements : 

7.  Assert  statement  of  the  form 

assert  assertion 

8.  Maintain-while  statement  of  the  form 

Maintain  assertion  while  condition  do  statement 

The  features  (1)  to  (6)  have  the  usual  ALGOL  60  semantics. 

The  effect  of  the  execution  of  an  assert  statement  is  the  following: 
The  assertion  is  evaluated.  If  it  is  true,  then  control  passes 
to  the  next  statement;  if  false,  an  error  exception  occurs.  The 
effect  of  the  execution  of  a  maintain-while  statement  is  the 
following:  The  assertion  is  evaluated.  If  it  is  true,  then  the 
while-do  part  is  executed  according  to  the  usual  semantics;  if 
false,  an  error  exception  occurs. 

A  variable  occurring  in  any  statement  (3)  through  (8)  (as 
a  left-hand  part  or  an  operand  in  any  condition  or  expression) 
must  be  a  variable  in  whose  scope  the  statement  occurs,  that  is, 
must  be  a  variable  in  the  "environment"  of  the  statement  (see  [1]). 
However,  a  variable  occurring  in  an  assertion  in  any  statement 
(7)  or  (8)  may  be  a  variable  of  the  environment  of  the  statement 
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or  it  may  be  one  of  the  special  variables  o,i^,...,im  where  m 
is  fixed  for  each  program.  Of  these  variables,  o  is  called  the 
output  variable,  and  ij  are  called  input  variables.  The  need 
for  these  variables  will  be  clear  later. 

PL,  the  source  language  for  our  verification  model,  is  much 
simpler  than  the  source  languages  used  in  the  execution  models 
of  [1,5],  yet  it  contains  more  features  than  in  [6,7],  say.  The 
verification  model  can  be  easily  extended  to  include  in  PL  such 
features  as  multiple  assignments  of  ALGOL  60,  collateral  (parallel) 
assignments  of  ALGOL  68,  for  and  repeat  statements  of  PASCAL, 
array  data  type,  and  functions  without  side-effects.  But  the 
incorporation  of  general  procedures  seems  difficult. 
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The  Verification  Model:  Preliminaries 

In  the  execution  model  [1,5]/  the  lambda-expression  repre¬ 
sentation  of  each  statement  (of  ALGOL  or  PASCAL,  say)  has  been 
derived  using  the  following  idea:  Each  statement  in  a  program 
may  be  thought  of  as  manipulating  1)  the  variables  accessible  at 
the  time  the  statement  is  executed  (these  constitute  the  statement's 
"environment") ,  and  2)  an  entity  identifying  the  point  in  the 
program  that  is  being  executed.  This  entity,  called  the  "continua¬ 
tion"  or  "program  remainder",  is  nothing  but  an  eventually  re¬ 
cursive  description  of  the  entire  portion  of  the  program  not 
executed  so  far.  The  statement  can  therefore  be  translated  as  an 
abstraction  with  respect  to  the  continuation  (denoted  by  the 
variable  <f>)  and  the  indeterminates  representing  the  program 
variables.  Referring  the  reader  to  [1,5]  for  the  actual  details 
of  representation,  we  give  below  some  examples  of  translation  in 
the  execution  model. 

Example.  Some  translations  in  the  execution  model 
Environment:  (x,y,x) 

Statement  Representation 

y:=x+3;  a=X<J>xyz  :  <j>x  (+x3 )  z 


if  y=l 
then 

z  :=0 

else 

x:=z+l ; 


b=At|>xyz :  (=yl) cd<f>xyz,  where 
c=A<j>xyz  :<J>xyO 
d=A<j>xyz :  <t>  (+zl)yz 


while  y>x  do 
x:=x+z; 


eHA<)>xyz :  (>yz)  (f<t>Hxyz 
f  =  A4>xyz  :  <J>  (+xz)yz 


write  x+3?  g=X<|>xyzo :j)xyzo;  (+x3) 

read  x,z;  g=X<J>xyzoi^i2  :  (fii^y^o 

The  representation  of  variables,  constants,  operations, 
relations,  and  expressions  in  the  verification  model  is  the  same 
as  in  [1,5].  But  when  translating  statements,  we  need  some  other 
constituents  besides  the  continuation  and  the  environment.  These 
are : 

Variable  Stacks.  There  is  a  fundamental  difference  between  the 
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execution  of  a  conditional  statement  for  a  numerical  result  and 
the  symbolic  evaluation  for  generating  verification  conditions. 
Whenever  a  conditional  statement  is  reached  during  a  numerical 
execution,  some  condition  is  evaluated  and  according  to  the 
result  of  the  evaluation,  the  first  or  the  second  branch  of 
the  statement  is  taken.  In  the  verification  context,  however, 
we  actually  have  to  execute  both  branches  of  a  conditional 
statement,  and  moreover  it  is  essential  to  start  the  computation 
of  each  branch  with  the  same  values  of  the  various  program  var¬ 
iables.  We  solve  that  problem  by  keeping  a  stack  for  every 
variable.  Each  time  we  encounter  a  conditional  statement,  the 
current  values  of  the  program  variables  are  pushed  on  the  stack, 
and  when  we  pass  the  corresponding  ELSE  these  values  are  retrieved. 
Assertions.  Essentially  what  we  have  to  do  in  order  to  generate 
the  verification  conditions  for  a  program  is  to  traverse  every 
basic  path  of  the  program  between  inductive  assertions  and  output 
the  lemma : 

"assertion  at  start  point  &  path  condition  3  assertion  at  end 
point  with  appropriately  changed  values  of  variables". 

So  we  need  some  constituent  which  allows  us  to  store  the  asser¬ 
tion  of  the  start  point  and  successively  add  the  path  condition. 
This  leads  us  to  the  concept  of  an  assertion  constituent. 
Verification  conditions.  Whenever  a  verification  condition  is 
generated  we  want  to  store  it  in  some  constituent  which  finally 
will  be  the  output  of  the  whole  process. 

Thus  the  translation  of  a  statement  into  the  verfication  model  if 
of  the  following  form: 

X  ♦  t  a  v,  a,  ...  v_  o_  o  ♦'t 1  o'  . . .  vn'on'o' 


program 

remainder 


4>  x  a  v,  a.  ...  v  a  o  :  <j> 

I  j  .  11  /  y  n  j  1  |m 

:aml  asser\  output  \  'N 


y 


conditions 


new  values  to  reflect  the 
effect  of  the  statement 


program 

variables 


Following  are  some  definitions  and  abbreviations  that  will 
be  used  later: 

I  =  Xx:x  (Identity,  null  list  or  triple) 
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8  =  (Xxy  :xx)  (Xxy  :xx)  (Undefined  value) 


<al 9  *  * 

. /an>  =  Xx:xa^. 

. .  aR ,  n 

(list  or  triple) 

S11  5 

Xx:xl 

(Note : 

sll<a> 

S21  5 

Xx:x(Xxy  :x) 

(Note : 

s21<a'b>  a^ 

S22  E 

Xx:x(Xxy :y) 

(Note : 

s22<a,b>  -*■  b) 

a;b  = 

Xx:axb 

(Note : 

<a1,...#ah>;b  <&ir. . . ,an,b>) 

push  =  Xxy:<x,y>  (Note:  push  ab  -*■  <a,b>  +•  a;b 

push  <a1#...,a  >b  -*■  <alf . . .  ,an,b>) 
pop  2  s22  (Note:  pop  <alf . . .  ,an,b>  -*■  b) 

add  =  Xxy:£ush( (s2ly) &x) (s22y) 

(Note:  add  a<b,c>  ■*  <b&a,c> ) 

ch  =  Xx:£ush(s21(s22x) )  (gush(s21x)  (s22  (s22x) ) ) 

(Note:  ch<a,<b,c>>  ■*  <b,<a,c» ) 

comb  =  Xx:£ush ( (s2^x) v(s2^ (s22x) ) ) (s22 (s22x) ) 

(Note:  comb<a, <b, c>>  <avb,c> ) 


Translation  Rules 
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Using  the  notation  of  [1]  (to  which  the  reader  is  referred 

for  motivation  and  explanation) ,  we  now  list  the  translation  rules 

of  the  verification  model.  These  rules  have  the  form 

(S}E  =  the  lambda-expression  representing  statement  S 

in  environment  E. 

Assignment  statement 

(v.  :=e},  „  .  (e  is  an  expression) 

i  ivlf...,vnJ 

=  HT0.vlOr  .  •  vnonHTQlv1c1. . .  vi.1oi.l{e}ai. . .  vnan 

Input-Output  statement 

{read  VjK  , 

e  X^tov1o1.  •  •  Yn°x!*Tavlflr  *  ‘  vi-lai-lXoivi+lai+l-  ‘  ‘  vnan° 


{write  e) 


(v.  , .  •  •  ,v  ) 


1' . n' 

=  X^tuVt  . . .v„o_o:4>xav1  o, . . . v_o_o; {e} 
i  l  n  n  11  n  n— 

Compound  statement 

{begin  Sjtfjj. .. >Sn  end)  ^ . ^ 

=  X <J> :  {S1H{S2H...  ({Sn}*)  ...)) 

Blocks 


{begin  <type>u1 ; . . . <type>um;S1;S2 ; . . . ;S  end} .  .  >v  , 

f  1  *  *  *  n ' 

5  X  <^>Tct :  {S,  }_  (  {S^}_(>  . .(  {S  }„  (Xxotu.  a  ...u  a  :  <f>xa) )...))  xaftlfil. ..  fil 
IF  ^  F  pr  1  Ui  m  u_  - 

1  m  _  _ 


m  times 


where  F  =  (u^,. . . »uro'vi'* • • »vm)  =  the  environment  extended 
by  the  newly  declared  variables  of  the  block. 

Since  in  the  verification  model  the  current  assertion  a  and  the 
list  of  verification  conditions  x  precede  the  representation  of 
the  variables,  we  have  to  include  ct  and  x  in  the  specification  of 
a  block. 

For  every  new  variable,  which  is  introduced  by  the  block, 
we  need  a  stack.  This  stack  is  initially  empty  (I)  and  has  to 
be  deleted  at  the  end  of  the  block  together  with  the  variable. 
Conditional  Statements 


{if  b  then  S.  else  S0).  „  „  * 

—  — —  i  2[v1,...,vn) 
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=  X<fr:as  ({S1>  (su({S2)  (sc  <j>)))). 

Subsidiary  definitions: 

as  =  X<j>xav^0^. . .  vnun :  <J>x  (gush  (s2^a  &  b) (add(~b) a) 
v1(push  v1a1) . .  .vn(£ush  vnan) 

This  takes  the  first  part  of  the  assertion  (which  represents  the 

valid  assertion  at  the  point  of  the  condition  statement)  s2^oi  and 

creates  two  versions  of  it,  which  in  addition  to  s2^a  also 

assume  b  or  ~b,  respectively.  Furthermore,  the  current  values  of 

the  variables  are  pushed  onto  their  stacks.  This  is  necessary, 

because  now  we  want  to  perform  the  statement  {S^},  which  might 

change  the  values  of  the  variables.  But  we  need  these  values 

for  the  execution  of  {S2)  later  on. 

su  2  X<J>xoiv.1a.1 . . .  va  :<{>t  (ch  (add(  v,=v.  &  ...  &  v  =  v  )  a) ) 

—  11  n  n  — —  -  11  n  n 

(s21al)  tpop  al)  •••  (s2lan*  (pop  an* 

This  saves  the  results  of  the  execution  of  {S^}  by  adding  them 
to  the  current  assumption.  Now  we  are  ready  to  switch  the  first 
two  branches  of  the  "assumption  tree" ,  which  causes  the  version 
containing  ~b  to  become  the  current  assumption.  For  the  following 
execution  of  (S2)  we  delete  the  action  of  {S^}  on  the  variables 
and  restore  their  old  values,  which  is  achieved  by  unstacking  them, 
sc  =  l<j>Totv^g.p  . .  vncrn:^T  (comb  (add(Vj=v^  &  ...  &  vn=vn)  a) ) 

Yr-Vr, 

This  finally  saves  the  results  of  the  execution  of  {S2  >  by  adding 
them  to  the  current  assumption.  Afterwards  the  assumptions  for 
the  then  and  else  clauses  are  combined  to  a  single  one  by  disjunction. 
Since  the  results  of  both  {S^  and  {S2>  are  now  saved  in  the  current 
assertion  and  are  denoted  by  v^,  we  make  v^  the  new  value  of  v^. 

Note:  The  second  form  of  IF-statement 
<i£b  then  S)(Vi . v 

is  translated  into 

X<(>:as  ({Sj^  (su(I  (sc  <j>) ) ) ) 
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Assert  statements 


{assert  a(vlf. . . ,vn,o) } 

=  X<j>xoiv^a^. . .  v^°n0'  s  ?  (s21aOa' )  (sub  a  a) 


v, o7 . . .vno„o 
xx  n  n 


where 


a'  =  a(v^...,v^o») 
sub  =  Xxy  :push  x  (s22y ) 

The  lemma:  "current  assertion  =>  a  with  the  variables  replaced 
by  their  current  values"  is  added  to  the  verification  conditions. 
Afterwards  the  current  assumption  is  replaced  by  the  assumption 
a  and  we  delete  the  former  values  of  the  variables. 

Main tain-while  statement 

{maintain  a  while  b  do  S} 

=  X(j>Tav1a1. . .  vnan:astCad1({S}  (ast  (ad2  j>) )  ) )  xaVj^. .  .vnan 

where 

ast  =  X<j>xav^a^. . .  v^ano'  :  4>x  ;  (s2^a  Da' )  (sub  a  a) 

v.a. . .  .v  cr  o 
11  n  n 

is  a  representation  of  the  statement 
assert  a, 

ad,  =  X<t>TQtv,  a-. . . .  v_o_  ;  d>x  (add  b  a)  v,a,...vor 
— l  11  n  n  -  11  n  n 

adds  the  predicate  b  to  the  current  assumption. 

Now  the  statement  {S}  is  performed  and  afterwards  "ast"  checks 

whether  the  predicate  a  has  been  maintained.  This  procedure  sets 

up  the  necessary  verification  conditions  for  the  maintain-while 

statement.  What  remains  to  te  done  is  to  add  ~b  to  the  current 

assumption  and  examine  the  program  remainder: 

ad«  =  X<j>xctv.  a, . . .  v  a  :  <J>t  (add(~b)  a)  v.a,...v  a  . 

—2  11  n  n  -  11  n  n 
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Examples  of  Translations  from  PL  into  the  Lambda-calculus 

We  now  present  some  examples  of  translations  of  programs 
obtained  by  using  the  rules  presented  above.  The  program  statements 
have  been  tagged  with  identifiers  used  as  the  names  of  the  cor¬ 
responding  lambda-expressions.  In  writing  lambda-expressions , 
certain  notational  liberties  have  been  taken  in  order  to  make 
them  human-readable;  the  intended  correct  form  must  be  obvious  in 
these  cases.  Thus,  expressions  have  been  written  in  the  usual 
infix  notation,  rather  than  the  proper  postfix  lambda-expressions. 
Fcr  example, 

[gcd(n,m)  *  gcd(x,y)  &  x>0  &  y>0] 
has  been  used  as  a  shorthand  for 

(&(&  (=  (gcd  n  mX  gcd  x  y) )  (>_  x  0) )  (>_  y  0) )  . 

The  result  of  reductions  given  at  the  end  of  each  example  has 
been  obtained  by  means  of  a  computer  program  [2]  which  reduces 
lambda-expressions  to  their  simplest  (normal)  forms.  The  actual 
computer  print-out  is  included  with  one  example. 

Example  1.  Summation  of  a  given  number  of  consecutive  integers. 


Input  condition:  n>0  (n  is  input) 

Output  condition:  output  = 

begin  integer  m,s;  . p 

read  m;  (*The  value  n  is  assigned  to  variable  m*) . re 

s  :=0 ;  . . . .  al 

begin  integer  j;  . bAl 

js^lf  . a2 

maintain  . . . 

s=(j-l)*j/2  and  m=n  and  j<m+l . ast 

while  j<m  do  . adl,ad2 

begin  . bH2 

s :=s+j ;  . a3 

j:=j+l  . a4 

end 

end; 


write  s;  (*  s  is  appended  to  the  (currently  empty)  output* »wr 
file  o.  Thus,  s^1o“s  *) 
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assert  s^o  =  m*(m+l)/2  . ter 

end 

Final  Result . res 


Translations 

re  =  X<j>xa  ma  so  oi,  s  <)>Tai, asoo 
in  s  1  1  m  s 

al  =  X<j>xa  ma_sa  :  <j>xama  Oa 
in  s  ms 

a2  =  X<}>xaj :  <J>xal 

ast  =  X(j>xaj'o  .m'o  s'o  :<j»(x;  (s,,a^  [s'=(j '-1)  *j '/2  &  m^n'  &  j'<m+l])) 

J  ill  S  £*  i.  ^ 

(sub  [s=(j-l)*j/2  &  m=n  &  j<m+l]a)  ja.ma  so 

'  ~  ^  j  ill  S 

adl  =  X  j>xa:  <frx  (add  tj^m]a) 

ad2  =  X<J>xa:<J>x  (add  [j>m]a) 

a3  =  X(|»xaja  .mo  so„;<J>xajo.ma„Is+j]as 
T  "  j  m  s  T  J  j  m  s 

a4  =  X<|)xaja  j  :<j>xa[  j+l]Oj 

b£2  =  \<p:a3  (a4  <p) 

mw  =  X<J>:ast  (adl(bl2(ad2  *)))) 

bJLl  =  X(|)xa:a2  (mw(XxajOj  s <J>xoc) )  xafll 

wr  =  XAxoano  so  o :4>xcana  sa  (o;s) 

T  ms  ms 

ter  s  X^xam'o^'agO' :ij)(x;  (s21oi3Is11o,=m'*(m,+l)/2]) ) 

(sub  [s^^o=m*(m+l)/2]a)  ma^sOgO 
p  =  X<|)xa:re  (al  (bill  (wr  (ter  (Xxoanamsas  :  ^>xa) ))))  xafilfll 
res  =  p(Xxoo:x)  I  <;n>0,I>  In 

By  lambda-calculus  reduction,  we  obtain: 
res  -*•  <  [n>0  0=0  &  n=n  &  l<n+l]  ,  [s=-^  — *  &  H=n  &  i<!l+l  &  i<fc 

Z)  s+i  =  &  jt*n  &  i+l=Jl+l] ,  [s=1-^-—  &  Jl=n 

&  i<*,+l  &  i>H  s=-  ^  ]> 

Thus,  res  is  a  list  containing  the  three  required  verification 
conditions.  It  is  easily  seen  that  each  of  these  conditions  is 
true.  So  the  program  is  partially  correct  with  respect  to  the 
specified  input  and  output  conditions. 
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Example  2.  Square- root  program. 

Input  condition:  n>0  (n  is  input) 


Output  condition: 


output  =  max  k^>n 
k>0 


begin  integer  x,yx  ^2^2?  . p 

begin  . aa 

read  x;  (*  The  value  n  is  assigned  to  variable  x  *),..re 

(yl,y2fy3)  :=(0,0,1)  '  . al 

y2*-=y2+y3  . a2 

end? 

maintain  •««••••«••»•#••«•••••••••••••  mw 

2  2 

x=n  and  y^<n  and  y2=(y^+l)  and  y3=2*y^+l . ast 

while  y2<x  do  adl,ad2 

(y1»y2fy3)  :=(y1+ify2+y3+2,y3+2)  . . bb 

write  yx?  . . 

(*  y^  is  appended  to  the  (currently  empty)  file  o.  Thus, 

Sii°*yi  *>  , 

assert  (s^o)z<n  and  n<  ( (s^^o)+l)  d . ter 

end 

Pinal  Result . res 


Translations 


A  *  ^  W  A 

re  s  HTcxaxy1oyiy2oy2y30y3Oi1:4,Tc.i1axy1c.y^y2oi,2y3ay3 
al  =  l^exa^^y^  y^^Tax^Os^Oo^lo^ 

a2  =  Htaxaxy10yiy2oy2y3<Jy3:+tc<xo>ty1c,Yi[y2+y3)^2y3ay3 
aa  =  X<|>:re  (al  (a2  4>)) 

ast  =  X^Tox'o^^Oy  y^Oy  y^ay  :<|>(t?  (s21a=>  [x'=n  &  y^2<n 

«L  2  3 

&  y£»(yj+i)2  &  y3*2*y^+ij ) ) 

(sub  Ix-n  &  y2<n  &  y2-(y1+l)2  &  y3»2*y1+l] a) xa^j^Oy  y2cy  y3ay 

12  3 

adl  =  X$xa:$T  (add  [y2^x]a) 
ad2  =  X$xa:<frx (add  [y2>x]ct) 

bb  5  HTaxoJIylOyiy2oy2y:}oy3l*TaxOx[y1-Hl0yi[y2ty3-f2]0Y2[y3+2]ey3 
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nw  =  X$:ast  (adl  (bb(ast  (ad2  4>) ) ) ) 

wr  =  ^^^1oY^2oYY3oY^:^axc^1oYY2oYY3oY^o;Y1) 

ter  i  X^Tax'a^^ay^y^ay^y^ay^o' :<j)(x;  (s21ar>[  )2<n  &  n<  ( (s^o'  )+l?] ) 

(sub  [(s^o)2^!  &  n<  ( (s^1o)+l) 2]  a)  xo^t^y  Y2ay  y3ay  ° 

p  =  X<J>xa:aa(mw(wr  (ter  (Xtaxa^^y  Y2°y  y3ay  8  <frTt*)  > ) )  xafllGIfllftl 

1  2  3 

res  =  p(Xxao:x)  I  <n>0,  I>  In 


By  lambda-calculus  reduction,  we  obtain: 
res  +  <[n>0  O  0<n  &  1=1  &  1=1  &  n=n] , 

[y2<n  &  y2=(y1+l)2  &  y3=2y1+l  &  x=n  &  y2<x 

^(Yi+l)2^  &  y2+y3+2=  (y^+1+1) 2  &  y3+2=2  (y^D+l  &  x=n] , 

Iy2<n  &  y2=(y1+l)2  &  y3=2y1+l  &  x=n  &  y2>x 
^y2<n  &  n<(y1+l)2]> 

Thus,  res  is  a  list  containing  the  three  required  verification 
conditions.  It  is  easily  seen  that  each  of  these  conditions  is 
true.  So  the  program  is  partially  correct  with  respect  to  the 
specified  input  and  output  conditions. 


Example  3.  GCD  calculation. 

Input  condition:  n>0  &  m>0  (m,n  are  inputs). 
Output  condition:  output  *  gcd(n,m) 


begin  integer  x,y;  h 

read  x,y;  (*  Input  values  n,m  assigned  to  x,y  *) . ....a 

maintain 

gcd(n,m)«gcd(x,y)  &  x>0  &  y>0 . ast 

while  x^y  do  . . . adl ,  ad2 

if  x>y  then  . as,sc,d,e 

x :*x-y  b 

else  . su 

y :«y-x;  ...c 

write  x;  f 


(*  Value  of  x  appended  to  (currently  empty)  output 
file  o.  Thus  s^o=x  *) 


assert  gcd(n,m)=s13o 

end 


Final  Result 
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g 

res 


Translations 


a  =  X<j>xa  xaxyayoi1i2:<f’Taiiaxi2ay° 

ast  =  Xijuax'a^'ay  (s21a  ^Igcd(nfm)=gcd(x' ,y' )  &  x’>0  &  y’>0])) 

(sub  [gcd(n,m)=gcd(x,y)  &  x>0  &  y>0]  ajxa^ya^ 
adl  =  X^Taxa^g.. :  4>x  (add  [x^y]  a)  xa^y  a„ 
ad2  =  X(j>Taxa3cyg„ ;  j>x  (addlx=y1  a)  xa3[ ya„ 

as  =  X^Taxo^yCTy  :<))t  (£ushCs2^a  &  [x>y] )  (addlx<yl  a)  )x(push  xaJt)y(push  ya„) 
b  =  XfjjTaxa^gy :  <t»Ta  [x-y] 

su  =  X(J>Taxaxyoy  :ij)TchCaddl3G=x  &  y*y]a)  Cs-^jQ^rCpop  cr^}  Cs21gy)  (pop  ay) 


c  =  X^xaxg^ay  :<j>Taxgx[y-x]gy 
sc  =  X<f>xaxa  va  :(j>  x  comb  (add  I5c=x 


&  y=yla)xcxygy 


d  =  X4>  :as  (b  (su(c  (sc  <)>)})} 


e  =  X g> :ast  (adl  (d(ast  (ad2  «)>)))) 


f  5  X^Tctxa^CyOt^Taxa^ay  (o;x) 

g  =  X^xax'a^'ayO*  :$(?;  (s21a  roIgcdO^ir^Sj^o’;] )  I 
(sub  [  gcd  (n ,  m)  =s  ^o  ]  a )  xa^  ayo 
h  =  X(j>xa:a(e  (f  (g(Xxa  : <|>xa) ) ) )  xaftlftl 

res  =  h (Xxao :x) I< [n>0  &  m>01  ,  I>  I  n  m 


By  lambda-calculus  reduction,  we  obtain 
res  -*•  <  [n>0  &  m>0  3  gcd(n,m)=gcd(n,m)  &  n>0  &  m>0] , 

[gcd(n,m)=gcd(x,y)  &  x>0  &  y^O  &  x^y  &  x£y  &  x=x  &  y=y-x 
or  gcd(n,m)=gcd(x,y)  &  x>0  &  y>0  &  x^y  &  x>y  &  x=x-y  &  y=y 
3  gcd(n,m)=gcd(x,y)  &  x>0  &  y>0] , 

[gcd(n,m)=gcd(x,y)  &  x>0  &  y>0  &  x=y  3  gcd  (n  ,m)  =x1  > 

Thus,  res  is  a  list  containing  the  required  verification  conditions.  As 
each  verification  condition  is  true,  the  program  is  partially 
correct  with  respect  to  the  specified  input  and  output  conditions. 


Translations  of  individual  statements  into  the  lambda- calculus 
(Note:  L  stands  for  X  on  computer  input.) 


1  -  (L  PHI  (L  TAU (L  AL (L  VX(L  SX(L  VI  (L  SY  (L  01 (L  11 (L  12 
(PHI  TAU  AL  II  SX  12  SY  01))))))))))). 

•  % 

AST  =  (L  PHI  (L  TAU(L  AL  (L  VXP(L  SX  (L  VYP(L  SY  (PHI  (PSfi  TAD 

(  (S2 1  AL)IMP  (ECU  (GCC  N  B)  (GCC  VIP  VYP)  AND  (GE  VXP  0) 

AND  (GE  VYP  0)))) 

(SUB  (EQ0  (GCD  N  tl)  (GCC  VX  VY)  AND  (GE  VX  C)  AND 
(GE  VY  C))  AL)  VX  SX  VY  SY)  ))))))). 

ADI  =(L  EHI  (L  TAD  (L  AL  (L  VX  (L  SX  (L  VY  (L  SY  (PHI  TAU  (ADD 
(NE  VX  VY)  AL)  VX  SX  VY  SY)  ))))))). 

AD2  *  (L  PHI  (L  TAU  (L  AL  (L  VX(L  SX  (L  VY  (L  SY  (PHI  TAU  (ACC 
(EQU  VX  VY)  AL)  VX  SX  VY  SY))  ))))))  . 

AS  *  (L  PHI  (L  TAU(L  AL  (L  VX  (L  SX(I  VY(L  SY(PHI  TAU  (PSH 

(  (S21  AL)  AND  (GT  VX  VY) )  (ADC  (LE  VX  VY)  AL)  )  VX 

(PSH  VX  SX)  VY  (PSH  VY  SY)  )  ))))))). 

BB  =  (L  PHI  (L  TA  0  (L  AL  (L  VX  (L  SX(L  VY  (I  SY  (PHI  TAD  AL 
(-  VX  VY)  SX  VY  SY  )))))))). 

SO  =  (L  PHI (L  TAU (L  AL ( L  VX(L  SX(L  VY(L  SY  (PHI  TAD  (CH 
(  ADD  ((EQU  VXB  VX)  AND  (EQU  VYB  VY)  )  AL)  )  (S21  SX) 

(S22  SX)  (S21  SY)  (S22  SY)))))))))  . 

CC  =  (L  PHI (L  TAU (L  AL  (L  VX(L  SX  (L  VY(L  SY  (PHI  TAD  AL 
VX  SX  (-VY  VX)  SY)))))))). 

SC  =  (L  PHI  (L  TAD  (L  AL  (L  VX(L  SX(L  VY  (L  SY  (PHI  TAU  (COB 
(ADD  (  (EQO  VXB  VX)  AND  (EQO  VYB  VY))  AL)) 

VXB  SX  VYB  SY) )))))))  . 

D  =  (L  PHI  (AS  (BB  (SO  (CC  (SC  PHI)))))). 

E  =  (L  PHI  (AST(AD1  (D  (AST  (AD2  PHI)))))). 

F  =  (L  PHI  (L  TAU  (L  AL  (L  VX(L  SX  (L  VY  (L  SY  (L  01  (Phi  TAD  AL 

VX  SX  VY  SY  (PSH  01  V X) )))))))))  . 

G  =  (L  PHI (L  TA  U  (L  AL  (L  VXP(L  SX (L  VYP(L  SY  (L  OP  (Phi 
(PSB  TAD  (  (S21  AL)  IMP  (EQU  (GCC  N  B)  (S11  OP)))) 

(SUB  (EQO  (GCD  N  M)  (S11  01))  AL)  VX  SX  VY  SY  Cl))))))))). 

h  =  (L  PHI  (L  TAU  (L  AL  ((A  (E  (F  (G  (L  TAD  (L  AL  (L  VX  (L  SX  (L  VY 

(L  SY  (PHI  TAU  AL)  )))))))))  )  TAU  AL  CM  I  CM  I)  )  )  )  . 

HES  *H(L  TA U  (L  AL  (L  OUT  TAU)  )  )'  I  (PSH  (GE  N  0  AND  GE  K  0)1)1  N  L . 


Definition  of  auxiliary  objects 


20 


PSH  -  (L  A  (L  B  (L  X  (X  A  &))))• 

SEC  = (L  X  (I  Y  Y) )  . 

S11  =T  I.  (Alternative  definition —  T  =  ;yx  is  a  primitive) 

521  =T  K. 

522  =T  SEC. 

SUB  =  (L  TX  (L  V Y  (PSH  VX  (S22  VY)))j. 

ADD  ={L  VZ  (L  X  (PSH  ((S21  X)  AND  VZ)  (S22  X)))). 

CH  =  (L  VZ  (PSH  (S21  (S22  VZ) )  (PSH  (S21  VZ)  (S22  (S22  VZ))))). 

COB  =(L  VZ  ((PSH  (OF  (S21  VZ)  (S21  (S22  VZ)  )  )  )  (S22  (S22  VZ)))). 

Now  RES  should  reduce  to  a  list  of  three  verification  conditions. 
Due  to  the  definition  of  lists,  RES  has  the  form  <<<P>,Q>*R>. 

The  components  are  extracted  below  in  the  order  R,  Q,  and  P. 


S22  (S2 1  (S21  RES)). 

INPUT  OBJECT  IS... 

:  S22  (S2 1  (S2 1  RES)) 

REDUCED  OBJECT  IS... 

GE  N  0  AND  GE  H  0 

IHP  (EQU  (GCD  N  E)  (GCD  N  K)  AND  (GE  N  0)  AND  (GE  H  0)  ) 


S22  (S21  RES)  . 

INPUT  OEJECT  IS... 

:  S22  ( S2  1  RES) 

REDUCED  OEJECT  IS... 

OR  (EQO  (GCD  N  H)  (GCD  VX  VY)  AND  (GE  VX  0) 

ANC  (GE  VY  0)  ANC  (NE  VX  VY)  AND  (LE  VX  VI) 

AND  (EQU  VXB  VX  AND  (EQU  VYB  (“VY  VX)))) 

(EgO  (GCD  N  K)  (GCD  VX  VY)  AND  (GE  VX  0) 

AND  (G£  VY  0)  AND  (NE  VX  VY)  AND  (GT  VX  VY) 

ANC  (EQU  VXE(-  VX  VY)  ANC  (EQU  VYB  VY)  )  } 

IBP  (EUU  (GCD  N  E)  (GCD  VXB  VYB)  AND  (GE  VXE  0) 
INC (GE  V YE  0)) 


S22  F£S. 

INPUT  OBJECT  IS... 
:  S22  blS 


BEDUCED  OBJECT  IS... 

EQO  (GCO  K  K)  (GCD  VX  VY)  AN  0  (G£  VX  0)  AND  ( GE  VY  0) 
AND  ( Eu  0  VX  VY) 

IBP  (ECU  (GCD  N  H)  VX) 


i 
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The  Correctness  of  Verification  Model 

We  would  now  like  to  prove  that  the  verification  model  pre¬ 
sented  above  is  correct.  In  other  words ,  we  would  like  to  show 
that  the  translation  of  a  PL  program  according  to  the  above-given 
rules  indeed  reduces  to  a  list  containing  the  lambda-calculus 
representation  of  all  verification  conditions.  We  begin  with 
some  definitions: 

A  path  a  in  a  PL  program  is  said  to  be  basic  if  it 
— starts  with  an  "assert"  or  "maintain"  or  starts  at  the  beginning 
of  the  program, 

— ends  with  an  "assert"  or  "maintain",  and 
— does  not  contain  any  other  "assert"  or  "maintain". 

The  verification  condition  for  a  basic  path  a  with  starting 
assertion  q,  terminating  assertion  p  and  path  condition  y  (the 
condition  under  which  y  is  traversed)  is 
q  &  Y  ->  P, 

where  the  variables  in  q  are  replaced  by  the  result  of  performing  a. 

The  verification  condition  list  for  a  PL-program  is  a  list  of 
verification  conditions  of  all  its  basic  paths. 

The  predicate  after  an  "assert"  or  "maintain"  is  referred  to  as 
an  assertion. 

With  these  definitions  the  following  theorem  holds. 

Theorem:  If  the  assert  (and  maintain)  statements  in  a  PL-program 
P  contain  only  program  variables,  symbols  i^,...,in  for  the  input, 
the  symbol  o  for  the  output  and  constants,  and  {prog}  is  a  translation 
of  P  into  the  verification  model,  and  is  the  input  assertion, 
then 

{prog}  (Xtqo:t)  I  <a0,I>  I 
generates  the  verification  condition  list  for  P. 

Proof : 

(Xrao:x)  as  the  final  program  remainder  deletes  all  the  information 
but  t,  the  verification  condition  list. 

(*) 

We  show  that  for  all  basic  paths  leading  from  assertions  q^,...^^ 
via  path  conditions  y1#...,Yn  to  the  assertion  p  in  a  PL-program, 

(*)  Some  of  the  q^'s  may  be  equal. 
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the  corresponding  translation  into  the  verification  model  generates 
the  verification  conditions 

ql  &  Y1  =>  p(*> 

and 


and 

qk  &  Yk  m>  P^x) 

and  adds  them  to  x,  the  list  of  verification  conditions,  x 
denotes  the  values  of  the  variables  immediately  before  the 
assertion,  possibly  also  containing  the  value  of  the  output  var¬ 
iable  o. 

Proof  by  structural  induction: 
basis : 

q  and  p  follow  each  other  immediately,  after  execution  of  assert  q, 
a1  is  q. 

The  path  cond.  y  =  T. 

The  variables  hold  x^,...,xn. 
assert  p  generates  the  lemma 

s21a->  Pl*=x 

which  is  true. 
induction  step; 

(a)  Suppose  the  hypothesis  holds  for  arbitrary  P/q^/...»qjc  in  a 
PL-program.  Now  consider  a  PL-program  where 

• =e (Xj , . . • ) } 

assert  r 

is  substituted  for 
assert  p. 

Let  a  denote  the  stack  of  assertions  before  the  execution  of  the 
assignment,  which  is  the  same  as  the  one  in  the  original  program 
before  assert  p. 

Let  x  be  the  variable  values  before  the  assignment. 

If  we  now  let  p(x)  =  r (xx, . . . ,xi_1,e (xx , . . . ,xn) ,xi+1, . . . ,xn) 

we  know  from  the  hypothesis 

s  _ .  a  ■  >  d  I  — 

21  ^'x*x 

is  equivalent  to 
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A  ‘  Vj  ->  Pljp.5 

j®l » •  •  • fk 

and  furthermore  to 

/\  ^qj  &  Yr  _>  x-tx^,. ..  ,e(xlf. . .  ,3^) .  ,xn) ) 

j— 1 / • • •  *k 

(b)  Suppose  the  hypothesis  holds  for  arbitrary  p,qlf...,qk  in  a 
PL-program.  Now  consider  a  program  where 
begin  < type >  u^, . . . ,<type>  um; 
assert  r  (u^,. . .  /U^x^. . .  ,xn) 
is  substituted  for 
assert  p. 

Let  a  denote  the  stack  of  assertions  before  the  execution  of  the 
assignment ,  which  is  the  same  as  the  one  in  the  original  program 
before  assert  p. 

Let  x  be  the  variable  values  before  the  begin. 

If  we  now  let 

p(x)  —  r  (£1  / »  »  »  /  SI  f  x.  f  •  •  •  f  x  ) 
m 

we  know  from  the  hypothesis 

S21“  *’  Plxrit 

is  equivalent  to 

A  (qj  5  Yj  =>  Pl*-3c> 

j=l » • • • fk 

and  furthermore  to 

A  (qj  *  yj  M>  rlu-u!>,x=;> 

j® 1 f • • • / k 

Cc)  Suppose  the  hypothesis  holds  for  arbitrary  p,q1,...,qk  in  a 
PL-program.  Now  consider  the  program  where 
end?  ( <type  >u^ , . . . , <type  >um) 
assert  r(x.,...,x  ) 
is  substituted  for 
assert  p. 

Let  a. . .  stack  of  assertions  before  end 
x,  u. . .  variable  values  before  end. 

(1)  u^  did  not  overwrite  some  global  variable  x...  Then  if  we  let 
p(ulf...,um,x1#...fxn)  s-rfXj.,...  rxn) 


we  know  from  the  hypothesis: 

s21a  3>  p ^  u*u,x=x 
is  equivalent  to 

A  tqj  ‘  Yj  *>  pi*-;* 

j*l $ • • • #k 
and  futhennore  to 

&  =>  rlx=x^ 

,k 

(2)  If  however  overwrote  the  global  variable  ,  we  could 
change  the  name  of  u^,  so  that  this  phenomenon  does  not  occur 
and  we  get 

A  ‘qj  *  ->  rlx-;> 

j=*l,..  .  ,k 

(d)  Suppose  the  hypothesis  holds  for  arbitrary  p,q-L*...»qk  in 
PL-program.  Now  consider  the  program  where 
if  b  (xlf . . . ,xn)  then 
assert  r 


is  substituted  for 

assert  p (x^ , . . . ,xn) . 

Let  a. . .  stack  of  assertions  before  if 
x. . .  variable  values  before  if 
The  execution  of  the  i_f  changes 

a  *  to  <a1&  b(x),<ai  &  ~b(x),...>> 

and  leaves  x  unchanged. 

If  we  let 

p (x)  =  (b (x)  =>  r(x)) 
then  we  know  from  the  hypothesis  that 

s21a  -> 

generates  the  correct  verification  conditions 

/\  (qj  *  Yj  ■>  p<£n. 

j“l» • • • /h 
So 

s21o  &  b(x)  *>  r(x) 
which  is  equivalent  to 

s21a  “>  tb(x)  ■>  r(x)). 


Also  generates 

/\  C<3 j  &  Y-j  =>  P(x)) 


(q j  &  Yj  &  b  (x) 


j  If • a • fk  j“l f • • • fk 

which  are  the  correct  verification  conditions  for  the  paths 
leading  to  assert  r  in  the  modified  program. 
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=  >  r  (x) ) 


(e)  Suppose  the  hypothesis  holds  for  arbitrary  pfq^/...»qn  in 
a  PL-program.  Now  consider  the  program  where 
if  b(x)  then 


else 

assert  r(x) 
is  substituted  for 
assert  p. 

Let  a...  stack  of  assertions  before  if,  x...  variable  values  before  if 
The  execution  of  if  changes 

a  =  <a^/...>  to  <a^  &  bCxJ^a^  &  ~b(x),...>> 
and  puts  the  values  x  on  the  variable  stacks. 
else  causes 

<a^,<a^  &  ~b(x),...>>  to  be  changed  to  <a^  &  ~b(x)  ,  <a^,  . . .  >> 
and  the  variable  values  are  retrieved  from  the  stacks.  A  reasoning 
analogous  to  that  in  (d)  now  causes  s2^a  &  ~b(x)  =>  r(x)  to  be 
equivalent  to  the  correct  verification  conditions 
/\  Cqj  &  Yj  &  ~b  (x)  =>  r(x) ) . 
j =1 » •  • • »k 

(f)  Suppose  the  hypothesis  holds  for  arbitrary 

Pt#  q£»  pe ,  q?,...,  q®  in  a  PL-program 


if  b (x)  then 

begin 

• 

•  t 
assert  p  (x) 

end 

else 

begin 

• 

•  e 

assert  p  (x) 

end; 

f  0 

New  consider  the  program  where  assert  p  ,  p  are  eliminated  and 
replaced  by  assert  r(x)  after  the  if- statement. 


if  b (x)  then 
begin 

fend 

else 

begin 


end; 

assert  r(x) 

Let  a...  stack  of  assertions  before  pt 
a'...  stack  of  assertions  before  pe 
a"...  stack  of  assertions  after  if-statement 
xt. . .  variable  values  before  pfc 
x®...  variable  values  before  pe. 

From  the  induction  hypothesis  we  know 

s21a  s> 

is  equivalent  to 

A  *  Yj  ->  Pt(xt)) 

j=l t  • • • »k 
and 

s2l“’  -»  Pe(5*> 

is  equivalent  to 

A  tej  &  Yj  pe 

9  •  •  •  #L 

a'  ■  <82^0' &  3c»xtf...>> 

0"  *  <(s21a  &  X=xS  v  (s21a'  &  x=x® ),...> 
the  variable  values  after  the  if-statement  are  x. 
Let  pfc(x)  =  (x»x  •>  r  (x) ) 
p®  (x)  =  (3p»x  ->  r  (x) ) 

So 


»21°'  ->  rt») 

is  equivalent  to 

^s21a  &  -> 

r(x))  &  (s2ia'  &  x=x® 

or 

(.2Xa  ->  P^x*)) 

&  <s2la*  -> 

lqj  *  Yj  ->  r(3jt)) 


*  f\  (q 


A 

• »k  j“l» • • • /L 

which  are  the  correct  verification  conditions. 


®  &  v® 

j  &  Yj 


> 


(g)  Because  of  (a)  -  (f)  we  know  that  for  all  PL-programs  without 
while- loops  the  model  generates  the  verification  conditions. 

Now  suppose  there  are  k  basic  paths  from  leading  to 

maintain  p(x) 
while  b(x)  do 
S 

We  want  to  add  the  lemmas 

qj  &  Yj  => 

to  t ,  where  x  denotes  the  variable  values  immediately  before  the 
main tain-while  statement. 

We  know  by  induction  hypothesis  that  if  we  replace  this  maintain- 
while  statement  by 
assert  p(x) 

the  model  will  generate  these  verification  conditions  at  that 
point.  But  we  observe  that  the  first  step  in  the  translation  of 
the  maintain-while  statement  is  exactly  to  perform  this  assertion 
Thus  the  desired  effect  is  achieved. 

The  only  way  of  entering  the  statement  S  is  through  assuming  p (x) 
and  b(x)  (which  is  carried  out  in  the  second  step  of  the  trans¬ 
lation  of  maintain-while)  and  we  can  leave  it  only  by  asserting 
p(x)  again. 

That,  however,  is  exactly  the  way  of  processing 
assart  p(x)  &  b(x) 

S 

assert  p (x) 

in  the  verification  model. 

So  we  know  by  induction  hypothesis  that  for  all  the  basic  paths 
ending  in  S  or  leading  back  to  the  top  of  the  maintain-while 
statement,  the  correct  verification  conditions  are  added  to  t. 

Finally  we  want  to  start  a  new  basic  path  by  assuming  p(x)  &  b(x) 
and  that  is  exactly  what  happens  in  the  model. 
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